IBIS Macromodel Task Group Meeting date: 03 September 2013 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Altera: * David Banas Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy ANSYS: Samuel Mertens Dan Dvorscak * Curtis Clark Steve Pytel Luis Armenta Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Brad Brim Kumar Keshavan Ken Willis Cavium Networks: Johann Nittmann Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: Michael Mirmak Maxim Integrated Products: Mahbubul Bari Hassan Rafat Ron Olisar Mentor Graphics: John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: Randy Wolff Justin Butterfield NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: Eckhard Lenski QLogic Corp. James Zhou SiSoft: * Walter Katz * Todd Westerhoff Doug Burns Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla Ray Anderson The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Need a volunteer to take minutes, Curtis to take the minutes. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - No ARs recorded - Radek had sent an email regarding proposed changes to BIRD 155.1 draft 6 ------------- New Discussion: Interconnect update: - None BIRD 155, New AMI API to Resolve Dependent Model Parameter: - Arpad: Radek and I exchanged several emails in the last hour on this - Radek: (reviewing the email contents) - Would like to have a discussion before changing the BIRD. - Three proposed options for modifying the draft: - (a) no change to current language. - (b) existing language plus some extra clarification. - (c) Somewhat different direction based on last week's discussion. - (b) adds an extra explanation: - AMI_Resolve() must be called first. - AMI_Resolve() is in the DLL called out in [Algorithmic Model]. - (c) stems from last week's discussion: - Would restrict use of an .ami file to AMI analysis flow. - Use of .ami file only for params for [External Model] in an AMI [Model]. - I prefer (b). - I believe Arpad prefers (c) (as a starting point for modifications). - I believe Bob prefers (a) or (b). - Arpad: Any questions so far? - Todd: Yes, what problem are we trying to solve here? - Arpad: (showing version 6.0 of the spec) - Parameter passing rules for [External Model] or [External Circuit] with .ami file currently only allow Usage In or Usage Info. - We're trying to change that to allow Usage Dep. - Radek: We're trying to address what you (Todd) brought up two weeks ago. - Todd: Is [External Model] in the [Model] keyword? - Arpad: Yes. [External Model] is, but [External Circuit] is not. - Todd: Okay [External Model] uses the legacy [Model] ports. - If I have an [External Model] with a parameter I want to sweep using .ami, does this text say I can't have a Usage Out parameter declared in that .ami file? - Arpad/Radek: No. - Arpad: The latest email I sent proposes wording to avoid that confusion. - Ambrish: Usage out is not allowed for Model Specific parameters. - Arpad: That's true, but it's not the question being raised here. - The language can seem vague, but the line in (c): "only Usage In, Usage Info or Usage Dep parameters are allowed," means that [External Model] can only reference these Usage types. - It does not mean that only these types can exist in the .ami file. - Radek: If you go back to IBIS 6.0, there are similar statements. - They are limited to parameter passing to [External Model]. - Arpad: (referring to (c)) - New restriction is that .ami file used with [External Model] implies [Algorithmic Model]. - I like (c), what it restricts may not be practically very useful. - Bob: Already required with [Algorithmic Model]. - Must have a .ami if you have a .dll. - Todd: But the converse is not true. Arpad is addressing the converse. - Arpad: - With the previous version of this BIRD, a parameter could have referred to an [Algorithmic Model] from under a different [Model] - Bob: That's true now. - Radek: - Now it's restricted to [Models] that do have an [Algorithmic Model] and it must use the same .dll. - Arpad: Imagine an IBIS file with Tx and Rx [External Models]. - External parameter for the Tx could have gotten its value from the Rx's .ami file. - New wording says that it can only come from the same Tx [Algorithmic Model]'s .ami file. - Ambrish: With 6.0, there are no restrictions. You can any .ami file that may belong to another .dll. - Bob: - It's just a file with parameters as far as the parameter passing mechanism is concerned. - If a parameter happens to be defined in the Rx or Tx, it's not a big deal. - Arpad: - That's correct as far as referencing the file and parameter. - But now with Usage Dep you need to know which .dll to use for Resolve. - Ambrish: Ah, right. - Radek: That's why option (b) has the new statements. - If we want to use Usage "Dep", the new restriction in (b) must be followed. - Walter: About two months ago, I said it was a mistake to have Usage Dep. - Info, In, InOut, really has to do with flow of AMI_Init, GetWave, Close. - This group has gone with AMI_Resolve for two reasons: - Dependency Tables constrained relationships to PWLs. - Conversion routines could not be hidden with Dependency Tables. - We agree that those are good reasons for AMI_Resolve(). - But they're not reasons to introduce Usage Dep. - Independent and Dependent parameters can be so regardless of Usage Type. - We've just blown another 5 man hours on this topic. - I really think we should just get rid of Usage Dep. - If we use Dependency_Usage, it's much simpler. - Dependency_Usage In if it's an input to AMI_Resolve(). - Dependency_Usage Out if it's an output of AMI_Resolve(). - We need "Dependency_Usage" and should get rid of Usage Dep. - Arpad: To summarize, you are basically suggesting to replace Usage Dep with Dependency_Usage Out, correct? - Walter: Dependency_Usage is a new keyword. - All of these things we're playing with could be handled. - Arpad: I don't see how that would change the situation. - We'd still have the same logical problems to solve regarding how and when the parameters in the .ami file can be passed to [External Model] and/or [External Circuit]. - Walter: No, BIRD 160 is fine. Everything about Usage stays the same. - Radek: But that still doesn't solve Todd's problem. - Walter: We have a flow. For Any parameter that has more that one value: - The EDA tool selects from the allowed values. - Except for a Dependency_Usage Out, which depends on other parameters. - After user/EDA tool selects all set up stuff, the AMI_Resolve() is called. - All Dependency_usage out values are resolved and then can be used for Impulse response calculation, passed to AMI_Init(), etc. - Radek: That doesn't solve the problem of which .dll's AMI_Resolve() to use. - Todd: (addressing Walter) - We have two different problems. - This is addressing the "matched set" problem I proposed. - Which .dll provides the AMI_Resolve()? Make sure we have a matched set. - Walter: We have an [External Model] to point to an .ami and .dll [sic]. - Arpad: [External Model] doesn't point to any of those things. - Walter: If we have an [External Model] that points to an [Algorithmic Model] and we need AMI_Resolve(), doesn't that imply which .dll provides it. Duh? - Todd: (addressing Walter) - We take it to be common sense that it would be configured that way. - They just want to add language to make it explicit. - Walter: That relationship is fine. - Todd: Usage Dep does create a level of complication. - Walter is saying Dependency_usage would solve that issue. - In the Tx_r example, Tx_r would be an Info parameter. - He would add a leaf "Dependency_usage" that says: "The .dll is going to give you the value here when you call resolve...and then it will be used by the [External Model]. - Arpad: But that doesn't change the logic of the flow. - How would it change the logical question, regardless of what we call it? - Todd: Using a different syntax to accomplish the same goal, right? - Walter: Yes. - Decoupling Dependency from Usage. - Radek: I originally read and considered your "Dependency_usage" proposal. - I found it interesting. - The one issue was that Dependency_usage and Usage are not truly independent. - I thought it would take some more explanation of that relationship. - I thought the concept of Dep as a Usage was simpler. - Walter: - If it used to say "Info, In", now it has to say "Info, In, Dep". - maintenance nightmare. - Arpad: - I still don't see how making that change would help with this issue. - Todd: Usage Dep comes out of the model, right? - Arpad: It says it comes out of AMI_Resolve. - Todd: Okay, so on the S-param circuit with Tx_r and a voltage source... - For whatever reason the model is going to select a value for Tx_r. - I call AMI_Resolve, and it gives me back a Tx_r of 50. - How do I go map it back to the resistor in the [External Model]? - Arpad: - The value comes out of Usage Dep. - [External Model] has path to parameter file (.ami) down to parameter name. - Parameter will have Usage Dep. - So tool knows it calls AMI_Resolve first. - Then it passes value to [External Model]. - Todd: - Okay this is sort of overloading. - What I thought of as usage Info, Usage Dep means it comes back from .dll. - Where you see it you're supposed to know how to use it? - When it's Info, In, Out, I know something about what I'm to do with it. - If a .dll returns a value of Usage Dep, how do I know what to do with it? - Ambrish: Usage Dep is clearly an Info, but it comes from AMI_Resolve(). - Arpad: Todd, you are thinking of things from the AMI GUI perspective. - Here in [External Model] it will find parameters and "pointers" to where to get the value from. - An [External Model] in a [Model] statement is looking for a parameter. - The tool is going to go find the value of that parameter. - Todd: AMI_Resolve() and AMI_Init() will have the same input string? - Walter/Ambrish: Yes. - Arpad: There are 10 minutes left. I'd hoped to vote, but we are running out of time. - Radek: But we had enough discussion about the third option. - Ambrish: We can't have an .ami file in the same directory with the same name as another. - Radek: The OS won't let you do that ;). - Ambrish: Yes ;). - So where is the confusion that one parameter can be referenced by another file. - Radek: There is no confusion in the case of a Usage Dep parameter: - As long as you know the name of the .dll to use for AMI_Resolve(). - But .ami doesn't give you that. - Ambrish: Doesn't [External Model] link to [Algorithmic Model]...? - Radek: Yes, that's what we're saying here in this section. - I want to know if we want to go with (a), (b), or (c). - Real question is do we want to restrict usage of .ami in [External Model] to AMI flow? - In that case you must have .ami and .dll. - Ambrish: If Usage Dep, doesn't it imply that there's a .dll. - Radek: Yes, but which one would you use to call AMI_Resolve()? - Arpad: My Tx, Rx example to Bob might have been wrong. - Ambrish: (b) and (c) are the same. - Radek: Careful, no. - (b) there is no restriction. - if you want In or Info you can use .ami for parameters but don't need a .dll - (c) restricts .ami file usage only to AMI flow (must have .ami and .dll). - Ambrish: I agree with (b) in that case. - Why restrict it in the case where there's no need for an algorithmic model (.dll)? - Radek: My understanding is Bob also prefers (b). - Bob: Yes, quick editorial questions on (b): - I prefer "executable model" to .dll. Not platform specific. - Would we also have to have AMI's ResolveExists set to true? - Radek: Yes, the current version has that mentioned (ResolveExists). - Arpad: We're coming to the end of the meeting. - I don't mind (b). I just want to revisit the wording. - Radek: Wonderful. - Ambrish: four different places need to be changed. - Radek: yes. - Arpad: I just liked (c) because I didn't feel the extra freedom was necessary. - Fangyi: I won't be around for the next two meetings. - Arpad: Okay, is it okay if we finish with Radek? - Fangyi: Sure. - Arpad/Radek: I'm glad we got this convergence on (b). - Arpad: Any more questions? (None) - Arpad: Now is a good time to stop. See you all next week. ------------- Next meeting: 10 September 2013 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives